home *** CD-ROM | disk | FTP | other *** search
- RELEASE NOTES FOR TELNETD.DEVICE
- ======================================
-
- *************************************************
- VERSION 0 REVISION 165 -- BUILT ON 6 Aug 93
- *************************************************
-
- Telnet.device requires either AS225 Release 2 or AmiTCP version 2+ to run.
- It also requires Workbench 2.04+ to operate properly.
-
- To install telnetd.device, do the following:
-
- 1) Copy the appropriate version of the device to your DEVS:
- directory. The device must be named telnetd.device. Thus,
- if you have AS225r2, at a CLI type:
-
- copy telnetd.AS225.device devs:telnetd.device
-
- Similarly, the command to use if you are running AmiTCP is:
-
- copy telnetd.AmiTCP.device devs:telnetd.device
-
- 2) You must create a configuration file for telnetd.device. For the AS225
- version, this file is called:
-
- inet:db/telnetd-device.conf
-
- The AmiTCP version is called:
-
- AmiTCP:db/telnetd-device.conf
-
- Lines in this file may be blank, start with a ';' character (for
- comment lines) or be a configuration entry. Configuration entries take
- the form of:
-
- <port #> <# units> <access list> [BLACKLIST <blacklist list>]
-
- <port #>, <# units>, and <access list> are all required. Specifying
- blacklist entries is optional.
-
- <port #> is the TCP/IP port to accept connections on.
-
- <# units> is the number of units to make available for <port #>
-
- <access list> is a list of networks to allow access to. This is not
- supported yet, and "255.255.255.255" should be used for the time
- being.
-
- If you wish to blacklist specific networks or hosts, place the
- 'BLACKLIST' tag on the line and then follow it by blacklist entries.
- Like the <access list>, blacklist checking is not implemented yet
- and thus you shouldn't try to specify any blacklist entries at this time.
- NOTE: Blacklist entries must be the last thing on the configuration
- line and must be preceeded by the 'BLACKLIST' tag.
-
- A sample config entry might look like:
-
- 23 5 255.255.255.255
-
- This tells telnetd.device to watch TCP/IP port 23 (the standard telnet
- port), allocating 5 units for that port. These units can then be
- accessed as telnetd.device unit 0 -> telnetd.device unit 4. If
- another config entry were to follow this one, it's first unit would
- be access as telnetd.device unit 5.
-
- NOTE: THE DEMO VERSION IS RESTRICTED TO PORT 5432 WITH 2 UNITS!
- The demo version does not make any attempt to read the configuration
- file.
-
- Now that you've got the device installed, try opening it with a terminal
- program. You should be able to type AT <carriage return> and have it
- respond with "OK". Typing AT$ <carriage return> will give you a complete
- list of all AT commands supported by telnetd.device.
-
- To properly monitor a port, you must run as many copies of your
- bbs/whatever software as you specified units for. I.e., if you asked for 5
- units on port 23 and you want Getty to handle logins, you would run 5
- copies of Getty on telnetd.device unit 0 through telnetd.device unit 4.
-
- When a connection comes in, the supervisor for the TCP/IP port looks to see
- which of its units have been opened. It then tries to find one that is
- currently available. If one is free, it hands the connection off to that
- unit.
-
- THIS RELEASE IS STILL A BETA VERSION!!
-
- Known problems:
- 1) file transfers with C-Net don't work. I have successfully done
- z-modem & other transfers between two terms (one running on
- telnetd.device, the other on tnser.device) though.
- 2) trying to use Terminus in IGNOREODU mode (thereby making Terminus
- use Begin() directly instead of calling DoIO()) results in
- character loss and/or incredibly slow throughput.
- 3) never returns SerErr_BufOverflow or SerErr_DetectedBreak. It
- does set the appropriate bits for this information in io_Status
- when a SDCMD_QUERY is done, though. I can't find any
- documentation that states exactly how these errors are
- handled. If anyone knows, please e-mail me.
- 4) the clients I have ignore my request for binary mode. thus,
- you have to specify binary on the client before telneting into
- telnetd.device if you want a full 8-bit clean pathway. if
- someone knows how to kick a client into binary mode remotely,
- please e-mail me.
-
- Still more or less untested:
- 1) serial code that makes use of SERF_EOFMODE
- 2) support for the ASDG serial.device extension SIOCMD_SETCTRLLINES
- 3) CMD_RESET, CMD_STOP, CMD_START, & CMD_FLUSH IO requests.
- 4) detection of a break signal from the other side (i.e.,
- when telnetd.device sees IAC BREAK, IAC AO, or IAC IP it
- should indicate that a break signal has been seen.
- 5) banging on this from various Unix varients of telnet to see
- if there are any problems with my options negotiations.
- 6) the AmiTCP version has not been tested at all since I don't
- have the ability to run the AmiTCP protocol stack.
-
- Other notes:
- 1) telnetd.device reports the baud rate at connect time based on
- the speed reported by the other side via the TELOPT_TSPEED
- option. If the other side doesn't support TELOPT_TSPEED, the
- device will report 19200 as a fallback. Note that the
- TELOPT_TSPEED handling hasn't been tested yet since I don't
- actually have a telnet client that supports this option... :-)
- 2) the ASDG serial.device extension SIOCMD_SETCTRLLINES is
- supported. However, I don't have any software that makes use
- of this so haven't been able to test it. The way it should
- work, though, is this:
-
- the RTS options are basically ignored, except that they
- will toggle the RTS line state reported by SDCMD_QUERY.
- RTS doesn't really map to anything in telnet.
-
- if DTR is turned off, the device should hang up the
- connection. it should also not allow any new connections
- on the unit until DTR is turned back on. If there was
- no connection at the time DTR was turned off, the unit
- should notify the supervisor that it can't accept any
- new connections.
-
- if DTR is turned on, the unit should inform the
- supervisor that it is now read to accept another
- connection.
-
- when a CMD_RESET is done, RTS and DTR should both be
- reset to ON status, notifying the supervisor as
- appropriate.
-
- 3) telnetd.device provides a full 8-bit clean pathway (provided
- the client asked for binary mode). it does not do any line
- ending translations, etc, as is normally done. it assumes
- that the software one is running on top of it does the
- translations needed. Since this is normally done anyway
- when talking to a modem, BBS software or programs like Getty
- generally do this anyway and this shouldn't be a problem.
-
-
- **************************************************
- VERSION 0 REVISION 241 -- BUILT ON 14 Aug 93
- **************************************************
-
- Minor change made to the telnet receive code which should result in less
- overhead in the buffer management routines. Resulted in a boost of about
- 700 CPS on ZModem file transfers between two terms running on the same
- machine.
-
- Lowered the stack size given to the supervisor and unit processes to 8192
- bytes.
-
- CMD_READ code updated to better support EOFMODE requests.
-
- CMD_READ now returns SerErr_BufOverfload and SerErr_DetectedBreak. The
- appropriate flags are cleared in the io_Status field when these are
- returned, so a SDCMD_QUERY right after one of these errors is returned will
- not indicate the condition. SDCMD_QUERYs done when no CMD_READ has been
- posted will indicate these conditions (and clear them).
-
- Implemented changes necessary to BeginIO to make it do CMD_READ immediate
- when there are no pending read requests and the buffer has enough
- characters in it to satisfy the read request without having to block. This
- fixed the problem with Terminus having very slow io/dropping characters
- when calling BeginIO directly (i.e., when it is in Ignore ODU mode). This
- also improved the situation with C-Net file transfers failing, but did not
- totally solve the problem with C-Net.
-
-
- **************************************************
- VERSION 0 REVISION 259 -- BUILT ON 17 Aug 93
- **************************************************
-
- Added rate pacing support in an attempt to fix downloads over a terminal
- server. telnetd.device would dump data to the terminal server at full
- ethernet speed. The terminal server would then have to downspeed to the
- modem speed, and overruns often occured. Pacing keeps telnetd.device from
- blasting away at the terminal server. Unfortunately, pacing didn't seem to
- fix the problems with the NetBlazer. Sigh. Pacing support is being left
- in, however, in case someone else finds it useful.
-
- Pacing is optional on a per TCP port basis. If no pacing is specified, no
- pacing will be done. If PACERATE is 0, then pacing will be done at the
- rate reported by TELOPT_TSPEED. Otherwise, pacing will be done at the rate
- specified. So, taking the earlier example of 5 units on port 23, a
- similiar config entry that paces data output at 19200 baud would look like:
-
- 23 5 PACERATE 19200 255.255.255.255
-
- Data being received from the client is not paced. Only data being output
- to the client is.
-
- Recomendations on how to set PACERATE are as follows:
-
- 1) If you experience to problems with overrun then do not
- specify a PACERATE at all. This will give maximum throughput
- and reduce the driver's overhead a bit as well.
-
- 2) If you experience overrun problems and have clients that
- fully support the TELOPT_TSPEED negotation, then set
- PACERATE to 0.
-
- 3) If you experience overrun problems, but have clients that
- do not support the TELOPT_TSPEED option, you must set the
- pace rate manually. For high speed modems, you probably
- want to set it to 38400 or 19200. For slow modems, you
- want to to set it at 2400 - 9600 most likely. If you
- have people connecting to a terminal server and then into
- a BBS, you might create bbs24 and bbs192 aliases on the
- terminal server that connect to different ports on the
- BBS. These ports would then have difference pace rates
- set.
-
- NOTE: THE DEMO VERSION IS FIXED AT A PACE RATE OF 9600 BAUD!
-
- **************************************************
- VERSION 0 REVISION 282 -- BUILT ON 18 Aug 93
- **************************************************
-
- Thanks to agnet.device in the release version of AmiTCP v2, I am now able
- to run AmiTCP and AS225 on the same machine concurrently. This has made it
- possible for me to test the AmiTCP version of the device, which appears to
- work exactly the same as the AS225 version (which is should). Yeah!
-
- There is, however, a bug in AmiTCP v2's WaitSelect() command that prevents
- it from waiting on a timeout value properly. Because of this, the delay
- that should occur between RINGs does not occur since WaitSelect() returns
- timeout immediately. This doesn't seem to affect the useability of the
- device, though. I have reported the bug to the AmiTCP guys. Jarno also
- tells me there is a bug in AmiTCP's gethostbyaddr() routine that can cause
- problems. Thus, Caller ID output may be trashed sometimes.
-
- Now defaults to ATE1 (echo on) at the request of several people. *sigh*
- I've always prefered echo off, myself.
-
- Implemented access restriction checking. At this time, subnet checking is
- not possible, however. Entries for the access list and the blacklist list
- should be entered in the following manner:
-
- if the entry is a net, enter only the net portion of the address.
- i.e., enter 128.135 only for the net 128.135.0.0.
-
- if the entry is a host, enter the full IP address for the host.
- i.e., 128.135.72.6.
-
- if you are intending to specify a net, and instead specify a
- net + local address (i.e., 128.135.72, in this case a sub-net
- of 128.135), then telnetd.device will interpret this as a host
- entry and no-one from the net will be able to connect (except
- for the machine with IP address 128.135.72.0 in this example).
-
- The access list must be specified. If you wish to allow access to all
- nets, specify a single entry of 255.255.255.255. Since the blacklist list
- is optional, you should not specify it unless you actually wish to
- blacklist someone.
-
- A couple of example configuration lines follow. All specify TCP/IP port 23
- with 5 units.
-
- 23 5 255.255.255.255 blacklist 128.135
- this would allow any machine except for those in the net
- 128.135 to connect to the machine.
-
- 23 5 128.135
- allow only those in the net 128.135 to connect.
-
- 23 5 128.135 128.248 131.193 blacklist 128.135.72.6
- allow any machine in the nets 128.135, 128.248, & 131.193 to
- connect with the exception of the specific machine 128.135.72.6.
-
- NOTE: THE DEMO VERSION RESTRICTS ACCESS TO THOSE MACHINES ON YOUR LOCAL NET!
-
- State related to the AT command parser is now stored by the supervisor
- process rather than the individual unit. Now, when you hang the unit up by
- closing & then reopening it (standard CBM hangup procedure), the unit will
- remember your AT command settings as well as the last caller information.
- Before, the unit would reinitialize this state information each time it was
- opened, and thus this information would be lost from one opening of the
- unit to the next.
-
- The new method is not totally fool-proof, however. If the unit you are
- setting options in is the only unit open, then closing and reopening it
- will cause the AT command set to be reset. This is because telnetd.device
- shuts down all supervisors when the last unit open is closed. Thus, the
- supervisor goes away and so does the state information. This is not viewed
- as a significant problem, however, as most usage of telnetd.device will
- have more than one unit open at the same time.
-
- **************************************************
- VERSION 0 REVISION 298 -- BUILT ON 29 Aug 93
- **************************************************
-
- This is a release candidate. The device basically hasn't changed since
- the last build. More testing was done, though. Found a bug in the delayed
- expunge handling. On Mike Sinz' recommendation, the device no longer
- supports delayed expunge.
-
- I have also created a .texinfo file of the documentation. This gives both
- an AmigaGuide file as well as beautiful text output via TeX. The DVI file
- is included. I may include a postscript file generated from the DVI in
- registered versions if people ask me for it since not everyone has a
- program that can deal with DVI files.
-
- ************************************************
- VERSION 1 REVISION 0 -- BUILT ON 31 Aug 93
- ************************************************
-
- First public release!
-